@danepowell, with this change, what would happen if Dependabot rebased a pull request? It seems to me that the updated pull request would not trigger a build. Does that sound right?

A rebase shouldn't be different from any other commit to a pull request in terms of workflow events. It will still trigger a new workflow run. We've been using this on Acquia CLI for over a year and Dependabot still happily does its thing: https://github.com/acquia/cli/blob/main/.github/workflows/ci.yml#L6

Okay, so just to make sure I understand you correctly, @danepowell, with this change, Dependabot PRs and rebases done by Dependabot will both trigger a build? But if a user pushes to a Dependabot PR it won't trigger a build? If I understand properly, the only behavior this would change is that if a human user commits and pushes up a new commit, the CI job won't run and the new commit won't be tested. Why is that desirable?

No, sorry; any commit (human or bot) will still trigger a build. The difference is this: today, any commit to a PR opened from a Dependabot branch will actually trigger two builds. After this change, such a commit will only trigger a single build. This is due to "pushes" (to a branch on the origin repo) and "pull request changes" being two separate events that aren't mutually exclusive.

An example: normally, developers open pull requests from feature branches on their forks, as I've done for this PR. In that case, GitHub Actions only fires a single event for any commit, e.g. pull_request or pull_request_target. But if you open a PR from a feature branch on origin, as Dependabot does, this fires two events: pull_request (as before) but also push. This is bad because some workflows aren't thread-safe.

So unless you have an unusual workflow with developers working directly on the origin repo, this basically only affects Dependabot.

Sorry, I thought I mentioned this in ORCA-568 but maybe not clearly enough.

This is due to "pushes"... and "pull request changes" being two separate events that aren't mutually exclusive.

Okay, that's key. In that case, this makes sense to me. @secretsayan, I would encourage you to add a brief inline code comment summarizing this discussion.

@danepowell : I see that you have edited the orca.yml in the example module, was this intentional or did you mean to change the orca.yml in the root directory instead?

@secretsayan I intended to change the example file since this is what downstream projects (such as my own) will reference.

If you want to update the root orca.yml, that's up to you. Let me know if you want me to add that to this PR.

@danepowell thanks for the information. I will add it to the root in a different PR.